home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group94b.txt / 000059_icon-group-sender _Tue Sep 20 14:41:36 1994.msg < prev    next >
Internet Message Format  |  1995-02-09  |  2KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 20 Sep 1994 08:32:44 MST
  2. To: icon-group-l@cs.arizona.edu
  3. Date: Tue, 20 Sep 1994 14:41:36 GMT
  4. From: eddie@festival.ed.ac.uk (Eddie Corns)
  5. Message-Id: <CwFnHC.Ds9@festival.ed.ac.uk>
  6. Organization: Edinburgh University
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <1994Sep4.220207.10360@midway.uchicago.edu>, <34gaps$ste@ios.com>, <34ok80$nnb@lowell.bellcore.com>
  9. Subject: Re: Icon - still alive??
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11.  
  12. norman@flaubert.bellcore.com (Norman Ramsey) writes:
  13.  
  14. >In article <34gaps$ste@ios.com>, Nick Williams <nmw@ios.com> wrote:
  15. >>I just don't see what is wrong with standardizing an Icon library of
  16. >>system specific functions. If standard would be welcome I would
  17. >>volunteer time to write/implement it.
  18.  
  19. >I would be thrilled.  To write my internet clients in Icon I have
  20. >resorted to the UGLY expedient of writing a C program that opens a TCP
  21. >connection, forces standard input and standard output to the
  22. >connection, then exec's an Icon program.  Of course, I can't easily
  23. >write servers this way if they have peresistent state :-(
  24.  
  25. After observing this thread for a while.
  26.  
  27. Icon is, as we all know, good at data processing.  Quite often if you rethink
  28. your strategy you can arrange to have a small program generate the data and
  29. then feed that data into Icon for processing.  This is after all one of the
  30. worthwile philosophies on which unix was based.  Obviously this wouldn't be
  31. suitable for all cases, especially where decisions had to be made on the
  32. contents of the data for subsequent actions.  Rather than try to reshape the
  33. language for system tasks, perhaps we could simply extend the I/O interface so
  34. that, given a suitable bit of code, we could open anything from a TCP socket
  35. to a directory to whatever.  If this all went through the open/read/write
  36. interface there would be no loss of portability and no trying to change the
  37. language away from its data processing style.  There would probably need to
  38. be an equivalent to ioctl as well.
  39.  
  40. Just a thought.
  41.  
  42. Eddie
  43.